The first thing we are going to do is fire up OllyDbg. Notice that we take all exceptions offered by Olly below: 

Figure 2.

We are opening up Olly with no target at this point. We are readying it to attach to our target.

Next we will fire up our target application and let it run to the familiar “Browser” Interface screen (which we will not show here, and yes, the target is a cheesy game, but hopefully, the principles you will learn here will be understood).

The “Browser Window” displays the usual 60 minute time limitation along with options to play the free trial or buy the full version. Note: the limitations imposed by the application are a direct result of the business rules used by the software vendor and are subject to change.

----

Back to Olly, go to the FILE menu, and select ATTACH and find our process, see below: 

Figure 3.

We will select Process (PID) 8B0, above, and attach. Note: Your PID will be different.

 ----

Don’t worry about the attached process stopping at the first system breakpoint below: 

Figure 4.

This is normal. What we are trying to do here, is simply find the instruction in the program we wish to break at, later. In Olly, the memory map window below should look very familiar to anyone that has dealt with this protection system: 

Figure 5.

As you can see, the target application is extremely bloated due to the protector. The bottom 4 sections of code are related to the 1^st layer of protection. We are interested in the second layer’s code EP. We will effectively bypass the first layer and most of the anti-debugging tricks by dumping at the 2^nd layer. The name of the sections can sometimes vary as will the size of our target’s 2^nd layer EP section. Look at section .rdata in memory block 006D1000 for a size of 00169000, above. This is the area of interest to us. Note: this section also includes the virtual ActiveMARK dll embedded in code. If you were to dump memory block 006D1000 and scan through it, you would see strange looking functions (see below) that would only make sense if you had the developer’s SDK, which we don’t:

Figure 6.

 ----

Back to Olly’s code window. We will see the following after attaching to the process:

Figure 7.

We don’t want to hit F9 to run our target, because ActiveMARK will detect us and terminate the threads and the process. So what we’ll do is the following:

Place your cursor on the first line and press the space bar, or using context help (Right mouse button – click), select Assemble and make the change shown below:

Figure 8.

We are cheating and want to jump to our code section of interest. After making the change, press F7 or step into the newly assembled code and you should land here:

Figure 9.

Using context help, select “Search for” and “All intermodular calls” shown below:

Figure 10.

On the “Found Intermodular Calls” result screen, press the destination tab to sort our results. We are interested in one of the basic API’s that are “usually” found in the procedure of interest near the 2^nd layer’s EP. We will use GetCommandLineA (address 0081661D) shown below:

Figure 11.

So, double-click GetCommandLineA above and we should land here in Olly’s executable code window at the darkened line below:

Figure 12.

Scroll up about 40 lines or so. We are interested in the first instruction of the procedure (see below):

Figure 13.

We are going to set a hardware breakpoint on execution for line 00816597 above. So go ahead and select this line, then using context help, select the following (shown below):

Figure 14.

 We can now close Olly (Don’t Exit) which will also close the target application. We will now Open our target in Olly. We will make one additional change to the debugging options in Olly BEFORE we run the target. We will select the “Break on new module (DLL) checkbox (see below):

Figure 15.

The reason we choose to do this is to slow the target down, while it runs, and avoid ActiveMARK detecting our debugger and forcing the process to terminate prematurely. The hardware breakpoint would never materialize. Why?? There are any number of reasons. Hardware (intel processor…) Software (WinXP vs Win9X), Executing Ring 0 (system code) vs (Ring 3) application code) Instruction alignment and what’s called RTDSC (Real Time Stamp Counter ) instruction, but not completely sure. You’re machine may be different. What is known is that ActiveMARK, in the later releases, has made strides in circumventing (read: bypassing) Breakpoints in memory and on access. So press OK on debugging options and F9 to run our target. On the “Executable module” screen in Olly, you will see the various dll’s load as the target application runs. Right after VERSION.DLL loads, we land at our Hardware Breakpoint (shown below):

Figure 16.

We are now ready to dump the process. DO NOT CLOSE OLLY.

----

Okay, the question you are all asking. Why don’t we dump at the OEP?? Good point. We talked about ActiveMARK using what’s called “asymmetric code blending”. This feature, more than anything else, is what separates this protection system from the rest and makes it a formidable opponent. We’ll jump to the program’s real OEP (shown below):

Figure 17.

Everything looks normal, or is it? Using context help, we’ll look at the following “found intermodular calls” window, in Olly, below:

Figure 18.

Where do you think all those calls referencing address 007????? Are going?? Right. We are jumping back and forth between the real program’s code and ActiveMARK’s code. If we were to double-click on any one of these calls (we will use the highlighted call above: Call MB2.00748BF3) we would land on the following in Olly’s code window (see below):

Figure 19.

Notice that there is a NOP instruction immediately preceding the CALL. ActiveMARK has stolen the real program’s import and replaced it with it’s own CALL. If we wanted to dump at the real program’s OEP, we would have to determine ALL the API’s (imports) that ActiveMARK has stolen and replaced with it’s own. Not an impossible task, but certainly more problematic than it’s probably worth. But more importantly, if this program had one of the interfaces noted above (i.e. Macromedia Flash projector, was a CD based app, had encrypted resource(s), etc.) ActiveMARK would check to see if a corresponding condition had been set earlier in the protector’s processing (read: data switch, Boolean switch, etc.) and if so, take the necessary actions,  “WHILE” the program is running. Remember, at this point, we are IN the real program’s code and not the protector. So…. if we were to follow the CALL above further, using context help, we would land here (see below):

Figure 20.

A bunch of obfuscated code. If we were to continue, we would eventually find the missing import.
(see below):

Figure 21.

After more jumping we eventually land here (see below):

Figure 22.

The stack window appears below, for the above:

Figure 23.

So that’s what this is all about. A missing import. And the process continues back to the next instruction in the real program. We don’t have to worry about this by dumping at the 2^nd layer.

 ----

Back to our goal. I assume you could use the Olly PE plugin to dump our process. I have chosen to use LordPE. Below are the options I generally use in LordPE for ActiveMARK:

Figure 24.

So find and dump the process in LordPE, (as shown below), but do not choose to rebuild the imports. We will do the imports next.

Figure 25.

After dumping, we will select the dumped.exe, again using LordPE or similar, and change the Entry Point and Base of Code. This will facilitate making changes in Olly later as well as updating the executable for the new EP. Since the original exe’s image base is at 00400000 we make the following calculations:

New EP = 00816597 – 400000 = 416597. Also, using the memory block mapping in Olly, we will change the Base of Code = 006D1000 (remember this) – 400000 = 2D1000.  (see below):

Figure 26.

We could also, if necessary, wipe (delete) the bottom four sections to make way for our new IAT section.  So go ahead and wipe away those last four sections, now, starting with the LAST section and working your way upwards to, but not including the .rsrc section at VOffset 00554000. Don’t forget to save and exit. Open the dumped.exe again using LordPe’s “Rebuild PE” option. Press OK and exit. If you are unfamiliar with doing this, read information on the use of LordPE and making changes to a PE structure.

Fortunately, this is one of the easier steps. Since we are rebuilding based on dumping at the 2^nd layer EP and not the real OEP, we can do the following:

Now fire up Imprec and find our process. Remember, we still have our session of Olly open with our target. After selecting the process (program), change the OEP to our new EP (shown below): Note: for demonstration purposes, your PID (process identifier) may differ from this Tutorial.

Figure 27.

Go ahead and press IAT AutoSearch. You will get something similar to following:

Figure 28.

Press OK.

Press Get Imports.

Generally, all, but the last THUNK are valid (see below):

Figure 29.

Go ahead and select the last Thunk (shown above, valid: NO) using context help, and select Delete Thunk(s).

You should now see the following in Imprec’s Log:

Figure 30.

So go ahead and press Fix Dump, in Imprec, referencing the name of the dumped.exe target that you saved earlier using LordPE. You should get a message back stating that the dumped file was saved successfully with the new IAT section added. We can now exit Imprec.

Back to Olly. We can now close the Original target application and open our New and improved dumped target with the added IAT section in Olly. So go ahead and do that now. You may also want to remove the debug event, in Options, we checked earlier, regarding loading dll’s. So uncheck this option. You will also note that Olly will analyze the new dumped exe. At this point, if we run our new target, we would see the following message in Olly’s bottom status bar: 

Figure 31.

----

So we scratch our heads a little and wonder, what happened!? Well a couple of things. First, we are bypassing the usual initialization steps because our new unpacked exe is of the wrong size (CRC) and therefore, ActiveMARK, cannot find, in memory, what it is looking for. So it rejects the application and goes to program exit. This is normal. Assuming we dumped our target in the right place and did our imports correctly, we can go to the next step.

We are now ready to make our one-time patch. To do this, we will once again, using context help in Olly, select “Search For” and “All intermodular calls”. Sort our results and we will now be looking for the following API name (GetModuleHandleA shown below). There are a bunch of them. 

Figure 32.

Usually, not always, the second occurrence of this API is the one we’re interested in. Select (double-click) line (Address) 0073D82E above. You will land here in the code: 

Figure 33.

We know we have found the right one, when we see the “Everything OK!” message above. BTW, if you land on that line, Everything is not okay, as you will surely go to Exit Process and be left wondering what went wrong! Note: the line of code at Address 0073D855, JMP instruction, is the jump to the original app’s OEP. You can check it out yourself. Shown below is that same line highlighted with a BP. 

Figure 34.

And Olly’s dump window below: 

Figure 35.

So our real OEP is at address 00469332.

----

Back to the “code window”. Scroll up a few lines and you will see the following code. The line we are interested in is highlighted below: 

Figure 36.

If we were to set a BP on this line and run the target, the value of the EAX register would be ‘00000000’. If things went as normal (not in this case), EAX would be equal to ‘1’. We want to avoid the JE (jump) on the next line, so, select the highlighted line above, press the space bar, or using context help, select assemble, as we want to change this line to look like the following: 

Figure 37.

Note: we could have moved a value of ‘1’ to [EBP-28] and compared it with ‘0’. We can now select our one line patch above, and, using context help, select “Copy to executable” “Selection” (see below): 

Figure 38.

We will see our change in a new code window. We can press “X” on this Window. Olly will prompt us (see below): 

Figure 39.

Press Yes and Save the dumped_.exe with a new name.

It is probably a good idea to rename your original *.exe and rename our new saved target to the original.

Run your new target. Congratulations! You should now have a working unpacked executable that will allow you to EVALUATE for a much longer period of time. Enjoy your newfound knowledge! In the case where this “FIX” doesn’t work…. You will need to read the next part of this series…. Advanced – Part II for a solution.

ARTEAM for hosting such a fabulous website and this Tutorial.